home *** CD-ROM | disk | FTP | other *** search
- Path: comma.rhein.de!serpens!not-for-mail
- From: mlelstv@serpens.rhein.de (Michael van Elst)
- Newsgroups: comp.sys.amiga.networking
- Subject: Re: Announce: AWeb 1.0 released!
- Date: 1 Apr 1996 19:37:33 +0200
- Organization: dis-
- Message-ID: <4jp48t$akq@serpens.rhein.de>
- References: <4joodb$74d@walrus.megabaud.fi>
- NNTP-Posting-Host: serpens.rhein.de
-
- petrin@walrus.megabaud.fi (Petri Nordlund) writes:
-
- > If rendering just means drawing the decoded images, then it
- > doesn't matter. But things like scrolling the document and
- > opening other windows like hotlists etc. must not be slowed
- > down by this.
-
- It isn't slowed down by this because it is not "rendering".
-
- > Ok, but why should rendering and decoding slow down network I/O?
-
- Just because something _has_ to become slower when the machine spends
- 100% of the CPU. Simple math.
-
- >>That's what AWeb does, although it runs the threads at the same fixed
- >>priority of 0.
-
- > Which doesn't make much sense because image decoding slows down
- > everything else.
-
- It doesn't slow down the GUI and it _should_ slow down rendering of the
- pages.
-
- > You must remember that when the decoder task
- > is running and you click on a gadget, the main task is not
- > waked up immediately, Exec will let the decoder task run for
- > a full quantum.
-
- Which isn't a problem. The quantum is small enough.
-
- > The result is that the main task gets LESS
- > than 50% of available CPU time to handle the GUI and user input.
-
- Not really. It just gets less when it needs less. If it needs several
- timeslices for an action then it is timesliced like any other CPU-intensive
- process.
-
- >>And this is something you do not need. Why should rendering stop decoding ?
-
- > Let's say you are scrolling the display, why should decoding make
- > scrolling slower?
-
- Scrolling is a job of the user-interface and not rendering a page.
-
- >>We have threads, thank you. And no, most systems schedule threads.
-
- > We have LWPs (Light-Weight Processes), not real threads.
-
- Obviously we have, one thread per task.
-
- > We need user-level threads run as a single process.
-
- You mean that we need multiple threads or tasks to be scheduled as a group.
-
- > All threads
- > share the same address space and are scheduled by a selectable
- > thread-scheduler.
-
- All threads/tasks in the Amiga share the same address space.
-
- --
- Michael van Elst
-
- Internet: mlelstv@serpens.rhein.de
- "A potential Snark may lurk in every tree."
-